STraTOS 1997 April & May/STraTOS 1 - 1997 April & May.iso/CD01/INTERNET/SITES/RAND/ALL95.LZH/transcript_1108/text0040.txt

Text File | 1995-11-26 | 10.9 KB | 217 lines

Hello
all!

This is just Doug sending out his first contribution to the BAD MOOD
mailing list, and letting everyone know my thoughts on the situation with
the project (and to clear up a few points of confusion - for me at
least!).

I would first like to congratulate everyone involved for attempting such a
daring feat of technology on a platform no-one really believes is capable
of sustaining it (except us of course!) and for sticking at it long enough
to make it at least a possible - if not probable
event.

Much like everyone else, I can't spend all of my waking hours on this
project (although it seems like it of late) as I have my work and other
menial problems to deal with throughout each week. However, I do intend to
write as many 'units' as possible - and offer them up as candidates for use
in BAD MOOD. I don't expect everything to be used, but I'll do my best to
make sure everything contributed is of the highest
quality.

Here are some thoughts, suggestions and personal opinions on the project so
far....


1) The sourcecode initially offered up to both Dave Murphy and myself was
only partially converted to assembly, and partially disassembled 'C'. We
have spent most of our time rewriting all of this code (including the
optimised code) - not for speed - but in order to understand how it works.
There was nothing wrong with the optimisations already made, but to leave
them unchanged would mean a gap in our understanding of those parts of the
program. There is only a small fragment of the code I have not finished
rewriting and I intend to have this cracked within a day or so. I do not
offer 'replacements' for the optimisations which were there already, as I
am not about to claim that my own optimisations are any better!, but
instead offer the source I have produced as a basis for understanding the
whole program. Basically, I hope people can use what I have written to
understand the principles in operation inside the Doom core and to allow
them to write their own replacement 'modules' for use later on in
development.

2) The code we have written, although as fast as we can make it without
affecting readability & presentability (i.e. no code-towers, precalc tables
and generated instruction sequences), is not optimised in the classical
sense. In other words - we haven't gone on a cycle-shaving excercise. I
expect somebody else might take it upon themselves to do this in the
future. I intend to write things clearly so that anyone can grasp what is
going on in there, and I will be depending mostly on data organization and
algorithmic improvement, as this is where most of the speed will come from
(including the DSP of course). I will make optimisations as I go, so long
as it does not affect clarity & limit future modification. The only
exception to this rule is the texture mapping at a pixel-level. This has to
be damn fast to say the least, and I will do my best to achieve this. This
means it might end up looking a bit nasty as a result. I don't expect this
to be a problem, and I can produce a simpler version for those who want to
mess with the
technique.

3) It is important to note that the original 'C' implementation of the
display engine is incomplete, and can never work correctly with floors &
ceilings without some minor additions. I have made these modifications
(although they are temporary - pending a new column-building unit) and will
explain them in detail with the source. I just don't want everyone looking
for bugs in their own versions of the display code that are actually down
to missing fragments of the drawing process! These 'missing fragments' are
not down to the lack of texturing or lighting effects, but rather a 'crack'
in the clipping algorithm. Bear this in
mind!

4) I would suggest that the organization of the program is not helping the
speed situation - the 68030's cache is being thrashed 98% of the time
inside the Binary Space Partitioning Tree and all of it's nested child
functions as these functions are called in a chained, linear fashion. The
cache doesn't get used, and the 68030's contribution to these areas in
future versions of the project is going to be hampered by this
problem.
I intend to reorganize the program to use a different (non-recursive)
tree-descent algorithm and force it to build tracking-lists for the sectors
to be drawn in the order the tree produces them. The NodeInCone functions
of the tree module (which has been now been redesigned completely to use
projection and other tricks) will be implemented on the DSP, which will
allow the entire tree-descent algorithm to fit inside the instruction
cache, and possibly even gain some parallelism with the DSP. Processing of
SSectors & Segs will be turned into generic 'loops' where the 3D & 2D
transformations can occur inside the cache, and without thrashing CPU
registers. The small overhead of reading/writing pointer lists & coordinate
groups will be more than eliminated by the greatly reduced instruction
fetch times. I have planned most (but not all) of the ordering required to
make this work and this will be my next task after the source
conversion.

5) I believe it would be a good idea to reserve the DSP for the heavy
arithmetic involved in 3D transformations, 2D projection, z-clipping,
right/left side of line calculations, edgebuffer generation, filling &
scanning the wall occlusion list, initial texture index calculations, and
bucket management for floors & possibly walls (depending on available space
inside the DSP). This is not an exhaustive list, but to clarify the
situation, I would like to suggest some areas to AVOID using the DSP. These
areas would be sound-fx, music, WAD file management, sector & linedef
management, enemy intelligence, BSP tree walking and any other generalised
ram-intensive or random-access job like those stated. To use the DSP for
the above would eliminate the ability to use it for the jobs where it is
really needed - and would save most time. I can clarify my reasons for
stating these suggestions if anyone finds this disagreeable. I would like
to stress that using the DSP for in-game sound would be a VERY bad
idea!

6) The mathematical accuracy of the program as a whole is too low to be
turned into a game. It's fine as a demo, but would look nowhere as smooth
as PC doom without being improved. An example is the player's location,
which is represented by 16-bit words. I suggest that all coordinate
information (except WAD-sourced wall coordinates) for the player, enemies
and things should be converted to 32-bit realnumber format - that is 16.16
fractional numbers. This offers fast, accurate vector arithmetic and a much
smoother game. I will strive to implement this feature into the display
engine, which will allow for sub-pixel positioning of textures - just like
PC
Doom!

7) I have written a fast (clipped & masked) scaled truecolour sprite
routine for another (previous) job which suits BAD MOOD perfectly for
drawing scaled THINGS on the floor and enemy objects. I have been tempted
to get the current engine to draw a Doom 'Imp' in the middle of each sector
using this routine, and I might do this before posting the code onto the
Internet. This does not mean I expect this code to be used, as the clipping
maths can be optimised a little (although it won't save much time!) but it
lets everyone play about with ideas without additional grief of writing
their own sprite
routine.

8) I would like to apologise to some of the BAD MOOD crew for pointing out
to Magnus Kollberg that the floor/roof bug was introduced to the code
through recent assembly optimisations (Sorry guys!) - this actually turned
out to be Jake Hill's fault when he put the algorithm together in the
original 'C' source! Unfortunately though, there were other bugs introduced
through optimisations (signed word-addressing on a big WAD file!) so it's
not such a completely unfounded statement. :) These bugs have been sorted
out in the latest version of my
source.

9) Dave Murphy has written a new WAD file parser which takes command line
parameters, and we are using this at the moment. Others may not want to use
this parser for their own reasons (they might have their own), and Dave has
left the code interchangeable in case somebody wants to swap the modules
about. I don't see any problems either way, and the more versions of
something there are - the more people obviously understand it!
:)

10) I think it's going to be too difficult to coordinate different people
working on different parts of the project at the same time, and it
certainly takes the fun out of it - which is bad news for a freeware
project. So it might be best for everyone to write the bits they want, and
offer them up for selection later on. This way, everything gets used
because it's the best final routine for the job, rather than because Mr 'X'
happened to be working on it. This does of course mean that some less
experienced members of the crew who are perhaps more familiar with 'C' or
even just the game side of the Doom engine might get a bit left out, but I
believe that even the most advanced parts of the program are based on the
groundwork of others who didn't spend so long on the problem themselves -
and the people who spend most of their time on the REALLY hard parts don't
have time to do the other bits, which are just as important at the end of
the day - and are definitely more abundant! There is plenty of work to go
round, especially considering we are tackling what is probably the most
advanced piece of code ever to hit the Atari platform (if we are to
succeed!).

11) I don't know yet exactly what direction the project is taking from a
game point of view - is to going to be Doom or a Doom clone? However it is
planned, are we going to get legal grief from ID, and do we have to get a
liscense? (I was quoted big figures by somebody close to ID for a
conversion to other platforms - even small
platforms).

Well, that about covers it from this end - hope this fills in some gaps and
lets people see what I want to. I just hope my ideas are not in conflict
with the general flow of
things.

I look forward to seeing any
feedback!

I am not in the mailing list just now (my internet supplier doesn't want
lots of mail exchanges taking place, as it's a free voluntary service!) so
any mail should be directed at my email address which is as
follows:-

[e-mail]

Otherwise I won't be able to read replies unless Magnus Forwards them to me
(and he can't do this all the
time).

I can also be reached on NeST in any of the general Falcon or programming
echos.

Bye!

Doug.

┌───────────────────────────────────────────────────────────────────────┐
│  Black Scorpion Software Developments   ≡≡≡≡≡≡≡   Falcon030 & Jaguar
│
├───────────────────────────────────────────────────────────────────────┤
│  Doug Little   ≡   Neil Stewart   ≡   Nick Hesketh   ≡   Dave Encill
│
└───────────────────────────────────────────────────────────────────────┘

--




----- End Included Message -----